bitkeeper revision 1.1371 (42692d136tRflIX7G4VOXJLCJstFVw)
authorkaf24@firebug.cl.cam.ac.uk <kaf24@firebug.cl.cam.ac.uk>
Fri, 22 Apr 2005 16:57:55 +0000 (16:57 +0000)
committerkaf24@firebug.cl.cam.ac.uk <kaf24@firebug.cl.cam.ac.uk>
Fri, 22 Apr 2005 16:57:55 +0000 (16:57 +0000)
commit6506ce0606f92758c324a5ecf4c885d382c2e548
tree4e83a032e733b0bfbe5c7cd481d010a8b9480413
parent5aacfef56353773b1c63e34559dc7dacd36ed375
bitkeeper revision 1.1371 (42692d136tRflIX7G4VOXJLCJstFVw)

Hi folks,

 arch/xen/x86_64/kernel/entry.S         |  131
+++++++++++++++++++--------------
 arch/xen/x86_64/kernel/process.c       |    5 -
 arch/xen/x86_64/kernel/traps.c         |    3
 arch/xen/x86_64/kernel/vsyscall.c      |    2
 include/asm-xen/asm-x86_64/hypercall.h |    5 -
 include/asm-xen/asm-x86_64/system.h    |    6 -
 6 files changed, 88 insertions(+), 64 deletions(-)

Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Attached contains bug fixes:
1. hang at floppy driver
2. hiccups at boot time
3. FP save/restore
4. cleanups in entry.S (critical section fixup, etc.)
5. time problem (temporarily disables vgettimeofday that uses TSC). I'm
not sure if we can use TSC-based vxtime in Xen. So we need some cleanups
there.

1 & 2 were simply fixed in process.c; xen_idle() is now identical to the
32-bit one.

I'm still working on failsafe_callback (because now I'm getting it), but
the system should be ready for broader ranges of people. Some config
seems to cause a panic in the hypervisor, and I'm also looking at it.
linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/entry.S
linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/process.c
linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/traps.c
linux-2.6.11-xen-sparse/arch/xen/x86_64/kernel/vsyscall.c
linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/hypercall.h
linux-2.6.11-xen-sparse/include/asm-xen/asm-x86_64/system.h